It is desirable to increasingly use resources in innovative ways, and further in open, distributed environments such as the Internet. Traditionally, usage policy specifications are controlled by the owner of the computing environment. The use of resources is generally restricted to closed computing environments that are managed by a single entity. However, with the increased use of Web 2.0 applications on the Internet, these restrictions no longer hold.
The term “Web 2.0” commonly refers to websites including applications that facilitate interactive information sharing, interoperability, and collaboration on the World Wide Web. A Web 2.0 website provides users with the option to interact or collaborate with each other in a social media dialogue of user-generated content in a virtual community known as an “open environment”. In contrast, a “closed environment” is one where users are limited to the passive viewing of content that was created for them. Examples of Web 2.0 websites include social-networking sites, blogs, wikis, video-sharing sites, hosted services, web applications, folksonomies and mashups.
Computing environments within which resources are used are no longer fixed, allowing resources to often move across multiple computing environments. This has led to problems, where resource owners demand that they hold the right to express the resource usage policy, rather than the owners of the computing environments. This trend is increasingly observed in usage management of commercial content, medical information and financial data. The advances made in using resources, such as mashups, aggravates this situation further. In order to address this problem, it is desired to have mechanisms that allow specification of usage policies that can be interpreted and enforced across multiple different computing environments.
Conventional designs in this area have been directed towards developing more expressive language by using either a different type of mathematical logic or formalism with greater reasoning capability. Such advancements, even though useful in closed systems, fail to address the problem of an interoperability challenge posed by open environments. The solutions that have tried to address interoperability have often resorted to translation mechanisms, where the entire policy is translated to a different language. Such translations are often infeasible, and difficult to carry out for most of the policy languages.
Other approaches to the problem have led to the development of complex policy specification languages that have tried to establish themselves as the universal standard. Such approaches require standardization of the complete policy language, which stifles innovation and flexibility.
The term “usage management” as used in the present application describes the management of resource usage within a given system. The historical development of usage management is discussed followed by the scope and constituent elements of usage management, tracing its origins to access control, digital rights management and the challenges that result from the evolving nature in which data and information is being used across systems.
Access control mechanisms are systems that manage controlled access to resources. The central idea behind access control is to grant access to a resource depending upon subject attributes, object attributes, and system attributes. The central component of any access control system is an Access Control Language (“ACL”) used to express rules for granting access to different resources in the system. Access control policies can be categorized into two types, namely, Discretionary Access Control (“DAC”) and Mandatory Access Control (“MAC”). DAC policies are the policies that are specified by the owner of the resource, based on the users' attributes. MAC policies are made by a central authority and apply to the whole system. A number of access control models have been developed that allow different types of access control in these two models. The most successful ones being the Role-Based Access Control model (“RBAC”), and the Bell and LaPadula model.
The focus of access control models is to capture the different types of relationships between and among a set of resources and a set of users, and express access rules based on those relationships. Access control mechanisms are generally tightly coupled with the system in which they are deployed. In situations where users' identities are not known a priori, a system agnostic authentication mechanism, such as the public key infrastructure, is used.
Digital Rights Management (“DRM”) consists of mechanisms that manage controlled usage of digital resources. The central idea behind DRM is that usage rules for a given resource are specified for a particular user or group of users, and the use of the resource is subsequently managed for a finite period of time. The usage rules generally include a set of permissions and obligations, along with rules specifying how the permissions may be exercised over a period of time and under what circumstances. DRM also includes mechanisms such as trusted computing that ensure the enforcement of rights on the user machines. The most well-known, but unsuccessful, approaches to address this problem are IBM's® Cryptolope and Microsoft's® Palladium technologies. Given the problem of enforcing DRM, there have been proposed incentive based, game-theoretic approaches for DRM. The central component of DRM systems is a Rights Expression Language (“REL”) that is used to express usage rules (or rights) in the form of a license that is generated by a resource owner for a user or a group of users that uses the resource.
Some of the earliest attempts at DRM involve the development of a formal language for legal discourse. At present, creative commons, along with two XML-based RELs, namely, eXtensible Rights Markup Language (“XrML”) and Open Digital Rights Language (“ODRL”), are most commonly used. Semantics of these XML-based languages are informal. A number of approaches using various types of formalisms and approaches have been used to develop formal RELs. Some have used trace-based semantics to develop formal RELs. Other formalisms such as first-order logic and CafeOBJ have been used to develop RELs. Others have attempted to provide formal semantics for existing XML based RELs. However, popular XML-based RELs are difficult to formalize in their entirety.
Others have tried to expand the concept of DRM to propose concepts including usage rights management and usage control. The idea of usage rights management is developed along the lines of making users aware of how a resource is supposed to be used. A more formal framework such as Usage Control that based on Authorizations, oBligations, and Conditions (“UCONABC”) combines access control and permissions and obligations in a single model. There are challenges in implementing usage management systems, and the need for an actionable framework for addressing the challenges.
There are differences between ACLs and RELs. Even though the goals of these two types of languages overlap, the focus of study in ACLs and RELs is significantly different. ACLs focus on defining access rules in terms of relationships between a set of resources and a set of users. In DRM systems, once a user obtains a license for a resource, access to that resource is implicit, and what matters is how that resource is used from that point onwards. RELs focus on defining different types of usage rules for a given user (or group of users) over a given resource (group of resources).
Unlike classical access control systems, information is increasingly used across highly networked, distributed computing environments that are not a part of a single centrally managed system. In addition, digital information is increasingly used in innovative ways in which it is transformed, processed or merged with other information while being used across computing environments. One such example is the mashup process where information from two or more separate sources is merged to generate a new information source. This necessitates usage management policies to be tightly coupled with the resource, rather than the system. The policy is then interpreted and enforced as the resource moves across different computing environments.
One approach to this problem is to build an interpreter for the policy language that runs on the computing environment such as the client, and enforces the policy on the client. This approach has been used for access control systems, because access control policies are tightly coupled with computing environments whose nature is known a priori. However, in usage management scenarios where resources move across environments that are not known a priori, such an approach is infeasible. To address such a situation, each of the computing environments must incorporate an interpreter and enforcement mechanism that is custom built for different policy languages.
One proposed solution to this situation is the use of a standard usage policy language for all types of information management ecosystems. Rights expression languages such as XrML and ODRL have been adopted separately as standards by different industry alliances. The semantics of these XML-based languages are informal, and there are problems involved in providing formal semantics for these languages.
Numerous formal logic-based rights expression languages have also been developed. These languages use different types of mathematical logics to express and reason over various types of usage semantics. Both XrML and ODRL have developed and continue to develop independent of these formal languages, and have not been able to incorporate their expression and reasoning power. For these reasons, none of these languages are likely to become the de facto industry standard in the future. Different information ecosystems continue to use different policy languages according to the policy expression requirements. Such a fragmented use of policy languages remains the biggest obstacle to achieving usage management along with unhindered flow of information across highly distributed computing environments.
The existence of multiple policy languages in such scenarios poses two problems, namely, difficulty supporting multiple languages and lack of interoperability. If a given computing platform that intends to be a part of multiple information ecosystems, it must support the policy languages used by each of these ecosystems. This means that policy language interpreters for each of these policy languages need to be custom built for that particular computing platform. Furthermore, any advances or changes that are made in these policy languages require corresponding updates in the interpreters used in the computing platform.
Another disadvantage is that even though a given computing platform may support multiple information ecosystems, each of these information ecosystems still operates in complete isolation from one another. Since different ecosystems use different policy languages, licenses expressed within one ecosystem cannot be interpreted in another ecosystem. This prevents resources from moving freely across different ecosystems.
The most common approach to interoperability has been translation mechanisms which translate a policy from one language to another language. It is, however, extremely difficult to translate policies from one policy language to another. The Coral and Marlin initiatives have provided architectural solutions to DRM interoperability. In the Coral approach, different licenses for different DRM systems are generated from a common token in accordance with a common ecosystem. In the Marlin approach, licenses are expressed programmatically in the form of control objects to prevent dependence on any one particular REL. Both Coral and Marlin architectures focus on the management of licenses across systems.
A license is a flexible vehicle that can be used in different situations such as access control systems, rules for content usage in digital rights management systems, specification of rules for missile launching systems, rules governing usage of medical records, and other such applications which necessitate controlled behavior. It is necessary to have a license structure that captures the range of license applications. In addition to the complexity of a license, it may vary depending on the applications. For example, a license can be as simple as an access control matrix or a license may involve complex semantics such as permissions, obligations, partial dependencies, parallel executions, interleaving semantics, management of state changes, etc.
While many applications do not require most of these semantics, certain applications may require specialized semantics that are different than the ones mentioned above. To capture each of these semantics, specialized logics have been developed that allow expression and reasoning over the concepts. For example, deontic logic captures the deontic concepts such as permissions and obligations, temporal logic allows reasoning over traces of activities, and dynamic logic allows reasoning over state changes. Different rights expression and access control languages have been developed that are able to expresses and reason over some of these semantics, but currently there is no single logic that can capture all of these semantics.
While there are many access control and rights expression languages with varying capabilities, using these languages in different applications presents the problem of interoperability. Typically, restrictions specified licenses are context specific.
Other issues arise with respect to mashups. The term mashup is used to describe a web application that combines data or functionality from two or more external sources. Mashup services are currently playing a vital role in the evolution of Web 2.0 applications. However, a number of problems are also emerging with respect to managing the rights associated with the constituent parts of a mashup, along with the rights that should be assigned to the resulting mashup service itself.
The resources made available through the programmable web are being used in increasingly sophisticated ways in order to provide useful results. For example, it is now possible for a website to contain news headlines, weather, blog entries, etc., each automatically delivered from external web services. Furthermore, applications that mashup geolocation and mapping services from external Internet providers with a company's own data are now common. That is, a mashup is created by aggregating data from different sources in presumably interesting ways. Mashups are a key capability associated with Web 2.0 applications, which are infrastructures currently emerging on the Internet.
Recently, a number of difficult issues have arisen regarding how the data associated with mashups can be used. For instance, because mashups generally involve the combination of someone else's data in order to create a new source of information, a number of ownership and copying issues occur. These include the agreements that are connected with the use of mashup sources, and protection of the intellectual property associated with a provider's proprietary information presented in a mashup, as well as new proprietary rights that arise when creative works are compiled in a mashup. In addition, there are a number of more obscure issues that arise in mashups. For instance, users may request warranties for the accuracy of mashup content. There are also questions regarding who is ultimately responsible for the content in a mashup.
Mashups may also present problems related to privacy. For instance, one website demonstrates that by combining two commonly available pieces of information, namely the current location of an individual, along with that individual's household address, such combination may allow someone to easily ascertain when that individual is away from their residence.
Currently many of the resources available via the programmable web for combining in a mashup have some terms of use or a license agreement associated with them. For example, Flickr™ associates a creative commons license with the content it delivers, and users must first agree to the terms of use before obtaining an Application Programming Interface (“API”) key allowing them access to Google® Maps. Indeed, if a mashup application is simply consuming the raw Hypertext Markup Language (“HTML”) returned by addressing some public website, there are typically terms associated with using this HTML. If an API is provided in order to obtain data from some web service, then typically one must first agree to the terms of use for the service, prior to obtaining an API key that is used for authentication. When accessing the service, the application must also supply the API key, and the resource is only delivered to the application if its domain matches the one associated with the key.
Because any addressable resource can be included in a mashup, anyone that maintains a website that can be accessed by the general public is at risk to the problems described above. Many of the above issues deal with how the data associated with mashups can be used. That is, they deal with the problem of managing property rights over mashups.
Recently, there have been a number of papers that consider security issues related to mashups. For instance, a number of groups have investigated the problem of cross-domain scripting in mashups. This problem arises from the browser security model that is used in typical mashups, allowing the scripts associated with a mashup source to change the data that was supplied by other mashup sources. Architecture was proposed that considered how to support authentication and authorization when dealing with non-public data in mashups. In this case, an API was provided that authenticated a user via OpenID, prior to providing data to that user.
There are different types of mashups that exist. In a client presentation mashup, the mashup program receives formatted HTML from data sources, often called widgets, and plugs them into the mashup program's web pages. A mashup editor is a tool that is typically used to create these mashup applications. In one example, a URL Builder module is used to create a query to a website. A text input is “wired” to this module in order to provide the search term, and then a number of additional modules are connected in order to filter the search results according to the user's criteria.
In client service mashups, the mashup program receives data from different sources. However, these sources are processed within the browser using JavaScript prior to presenting the mashup information to the end user. Finally, in external service mashups, a server collects data from different sources, and then processes it using a scripting language such as Ruby, PHP or Python, prior to presenting the mashup information to the end user.
FIG. 16 is a flowchart depicting steps that are typically taken in a conventional Internet environment to create a mashup. Typically, access to a particular source data is provided through an API. However, a user must first register with the provider in order to use an API. In the case of client presentation mashups, the creator of the mashup program may assume this responsibility. In the case of client or external service mashups, the mashup creator is typically asked to fill out an application that asks for the domain from which the API is accessed. In addition, the mashup creator must agree to the terms of service for the API, which often include various stipulations on how the data and service may be used as shown by 10. The provider then supplies a key 12 at each source 14 to the mashup creator 16 that can be used to gain access to the API from within the mashup creator's domain. Next, a mashup program that uses the API may be created. This is typically accomplished through an HTTP request 18. The mashup creator supplies a key with this request, and either data or javascript code that can be included within the mashup creator's application is returned 20 to the mashup creator 16. The mashup data is then provided 22 to the web browser 24.
It can be seen that the mashup scenario lacks one of the fundamental properties associated with digital rights management, namely machine actionability. Although it is common for there to be a large number of usage terms associated with the streams used in mashups, because they are not generally express using any type of REL, human intervention is required to interpret and perform any rights-related actions. Furthermore, this problem is difficult to address, as it cannot be solved by simply adopting a rights expression language for a given source. The very nature of mashups is that they may include sources from many different types of origins, and the sources may be used in ways that the originators of the sources did not initially anticipate. Thus, all sources cannot be expected to adopt a single REL. Rather, if a source even uses a REL, it should be expected to be different from the ones used by other sources. For instance, a mashup program might expect to encounter license agreements that make use of XrML, ODRL, Creative Commons, or the GNU General Public License.
Another problem relates to where rights should be managed within the mashup framework. After usage terms have been agreed to, they are effectively disassociated from the content. The owner of a particular source would like to continue to assert rights over how the source is used. However, the owner must now rely upon the owner of the mashup program to do this. In order to grasp the depth of this problem, consider FIG. 17. FIG. 17 demonstrates a mashup program 26 that replaces the web browser 24 of FIG. 16 and makes use of data provided by another mashup program 16 (see also FIG. 16). The mashup program 26 also receives data from other sources 28, and outputs mashup data 30. In this scenario, the initial mashup 16 (see also FIG. 16) becomes the effective owner of the resource, and the creator of this mashup must decide what restrictions and usage terms should be applied. This approach is fundamentally flawed, as the rights and usage terms should flow from the original sources, as the owners of these sources should have every right to assert them.
In order to address the problem of rights disassociation, it becomes necessary to compute the resulting rights that emerge from the initial mashup program 16. However, as the number of sources and the level of mashing increase, the complexity of computation associated with determining the unified set of rights associated with the target grows in a manner that is likely to be exponential. Furthermore, for a typical set of usage terms, it immediately becomes apparent that it is difficult to simply reason over the combined set of rights. For example, the terms of service associated with each API are thousands of words. Thus, even for a mashup involving a relatively small number of sources, simply determining whether or not the license terms of two or more providers conflict with one another is an extremely difficult task.
Moreover, the terms themselves can be complicated. For instance, some of the usage terms associated with the Google® Maps API include that a user cannot require a fee-based subscription for access to any site that uses Google® Maps, the user must display a link to the Google® Maps terms of use, a user must not modify the map data itself, the map data can only be used in a web browser, a user may not offer a batch geocoding service built using the Google® geocoding service, a user must not have the Google® logo as the largest on their website, and a user must not display a Google® Map if the site contains adult content. Understanding the meanings of these usage terms, along with their context and how they might be combined, is a challenge in and of itself.
In order for a computer to “understand” the context in which usage terms are being provided, an ontology must be supplied. This allows computers to reason over rights scenarios in mashups in order to answer questions such as whether the rights associated with different sources can be satisfied. For instance, a determination may be made regarding the following: whether the rights are defined consistently with respect to one another, whether the assumptions associated with a first source are consistent with assumptions in other sources, and whether different environments are conformal. For example, the concept of loaning a content object in an e-book environment may not have an analogous action in an environment dealing with corporate documents.
Therefore, there is a need for a system and method that allows resource usage to be utilized across and within computing environments including the use of different applications across and within different environments. The present invention satisfies this demand.